Distributed database management system with dynamically split b-tree indexes

ABSTRACT

A distributed data processing system for a database composed of data records organized into tables for responding to a request to split an index in a consistent and concurrent fashion. A request to split an index atom at any given node is processed by a designated “chairman” for that index atom. The chairman splits its index by maintaining a lower portion thereof and by moving the contents of an upper portion to a newly created index atom as the right sibling. Each other node takes appropriate steps to assure orderly transfer of this information from the chairman consistently and concurrently across the distributed database processing system.

CROSS REFERENCE TO RELATED PATENT

U.S. Pat. No. 8,224,860 granted Jul. 17, 2012, for a Database Management System and assigned to the same assignee as this invention is incorporated in its entirety herein by reference.

This application is a continuation of U.S. application Ser. No. 16/129,661, filed Sep. 12, 2018, for a “Distributed Database Management System with Dynamically Split B-Tree Indexes,” which is a continuation of U.S. application Ser. No. 14/215,401 filed Mar. 17, 2014, for a “Distributed Database Management System with Dynamically Split B-Tree Indexes,” which in turn claims priority from U.S. Provisional Application Ser. No. 61/789,479 filed Mar. 15, 2013 for a “Distributed Database Management System with Dynamically Split B-Tree Indexes.” Each of these applications is incorporated in its entirety herein by reference.

BACKGROUND Field

This invention generally relates to database management systems and more specifically to a methodology for splitting indexes in a distributed database management system.

Description of Related Art

Databases typically incorporate indexes for enabling the efficient retrieval of certain information. AB-tree data structure is a popular indexing structure that is optimized for use in databases that read and write large blocks of data and that enables efficient database searching. AB-Tree data structure includes a root and a plurality of leaves. The root uses a key value to identify a corresponding leaf. Each leaf points to any records that contain the key value. The key values are sorted in order, typically in a plurality of leaves thereby to form a sorted list. Specifically, a given leaf includes a “left sibling” and a “right sibling” that identify leaf to the left of and a leaf to right of the given leaf thereby to maintain a list in sorted order. The first or left-most leaf and last or right-most leaf include entries denoting the ends of the list of leaves for that root.

Typically each leaf has a fixed memory size. When a size threshold is reached, it becomes necessary to define a key value and to “split” that leaf into “left” and “right” leaves. The “left” leaf receives values that are less than the defined key value and the “right” leaf receives the remaining values with appropriate modifications to the root. In centrally based and non-shared databases, the splitting process is efficient because generally there is only one copy of the index in the database system. The split is easy to effect by quiescing the data processing system during the actual splitting operation.

Recently there has been interest in the development of distributed databases. The above-identified U.S. Pat. No. 8,224,860 discloses an implementation of a distributed database wherein user access is provided through a network of transactional nodes and complete copies of the information in the database are only stored on archival nodes that act as storage managers and are not directly accessed by users. More specifically, a user connects to a transactional node to perform operations on the database by generating high-level queries that the transactional node processes. In this implementation a given transactional node need only contain that data and metadata as required to process queries from users connected to that node. The data and metadata are defined by an array of atom classes, such as an index class, and atoms where each atom corresponds to a different instance of the class, such as index atom for a specific index. Replications or copies of an atom may reside in multiple nodes wherein the atom copy and a given node are processed in that node at least in part independently of each other. When an atom is created at a node, it is designated as a “chairman.” The designation of a node as a chairman can be transferred to a replication of that atom in another node.

In the implementation of U.S. Pat. No. 8,224,860 asynchronous messages transfer atoms and information about atoms among the different nodes to maintain the database in a consistent and a concurrent state. Specifically, each node in the database network has a unique communications path to every other node. When one node generates a message involving a specific atom, it can communicate as necessary with those other nodes that contain replications of that specific atom. Each node generates these messages independently of other nodes. So, it is possible that, at any given instant, multiple nodes will contain copies of a given atom and different nodes may be at various stages of processing them. As these operations in different nodes normally are not synchronized, it is necessary to operate the database so each user is assured that interaction is with a concurrent and consistent database.

Splitting an index in a distributed database such as disclosed in the above-identified U.S. Pat. No. 8,224,860 involves splitting replications of an index atom that performs as a leaf at the transaction node requesting the split and each archival node plus any other transactional node that has a copy of that index atom. It is possible for multiple nodes to request a split of a given index whereupon a race problem can exist with an erroneous outcome. Prior methods, such as those involving quiescence, are not readily applicable to implementations of a distributed database of the type discussed above without introducing unacceptable system performance degradation. What is needed is a method for handling requests for splitting an index in a distributed database wherein copies of the index are located in multiple locations.

SUMMARY

Therefore it is an object of this invention to provide an implementation of a distributed database that processes requests to split an index in a consistent and concurrent fashion.

Another object of this invention is to provide an implementation of a distributed database that processes requests to split an index in consistent and concurrent fashion without any significant performance degradation.

Yet another object of this invention to provide an implementation of a distributed database that processes a requested split of an index and eliminates the involvement of nodes that do not include that specific index.

In accordance with one aspect of this invention a distributed database processing system includes a plurality of nodes, each of which includes means for establishing communications with every other node wherein the database has an atom class for each category of metadata and data including an index atom class that provides an index atom for each index in the database and each index atom includes a range of key values. An index atom can be replicated to other nodes. An index atom is split when a node detects a need to split the index atom based upon a split key value that defines lower and upper portions of the index. Another node identifies a location in its index atom based upon the key value for defining the approximate lower and upper portions of the keys for the index atom, creating a second index atom as a right sibling to the first index atom, transferring the key values in the upper portion of the first index atom to the to the lower portion of the second index atom and transmitting to all other nodes with the identified index atom an index split message including the split key value. Each other node responds to the receipt of the index split message by deleting corresponding to the key values in the upper portion of the first index atom being split, retrieving the populated second index atom copy from the one node with the right sibling and sending a split done message to the one node chairman whereupon the one node broadcasts an index split done message when all other nodes have generated the split done message.

In accordance with another aspect of this invention, a distributed database management system includes a plurality of transactional and archival nodes wherein each transactional node responds to queries by interacting with a portion of the database thereat and wherein an archival node stores a version of the entire database. Communications are established at each node and every other node. The system has an atom class for each category of metadata and data including an index atom class that provides a B-Tree index atom for each index in the database. Each index atom can be replicated on demand to the archival node and at least one transactional node. One index atom in one node is designated as a chairman for that index atom. The process of splitting an index atom includes detecting at one of the transactional nodes a need to split a B-Tree index at that node and, if the node does not contain the chairman, transmitting a split index request message to the chairman node including the identification of the requesting node and a split key value. The chairman responds to its internal request for splitting the index or the receipt of the split index request message from another node by defining the contents of lower and upper portions for the index in response to the split key value, creating a second index atom as a right sibling of the index atom being split, moving the upper portion of the index for that index atom to the second index atom, and transmitting to all nodes that contain that index atom, an index split message including the split key value that defines the split for the lower and upper portions. Each non-chairman node responds by deleting from its existing index atom in response to the split key value the contents in the upper portion of the index atom being split and retrieving from the chairman the populated second index atom copy as the right sibling for the index atom being split. Each node transmits a split done message to the chairman. The chairman sends an index split done message when all nodes involved in the index split operation have reported completion to the chairman.

BRIEF DESCRIPTION OF THE DRAWINGS

The appended claims particularly point out and distinctly claim the subject matter of this invention. The various objects, advantages and novel features of this invention will be more fully apparent from a reading of the following detailed description in conjunction with the accompanying drawings in which like reference numerals refer to like parts, and in which:

FIG. 1 is a diagram in schematic form of one implementation of an elastic, scalable, on-demand, distributed database to which this invention applies;

FIG. 2 depicts the organization of a transactional node;

FIGS. 3A and 3B depict a local organization of “atom” objects generated by atom classes shown in FIG. 2 that might be present at any given time in any node.

FIG. 4 depicts the information of an index atom can be split in accordance with this invention;

FIG. 5 depicts the syntax of an exemplary asynchronous message that transfers between transactional and archival nodes of FIG. 1;

FIG. 6 depicts messages that are useful in one implementation of this invention;

FIG. 7 is a flow diagram that is useful in understanding the response to a request for splitting an index atom in accordance with this invention;

FIG. 8, comprising FIGS. 8A through 8D, depicts a sequence of changes to an index being split in both a chairman and non-chairman node;

FIG. 9 depicts an index split process executed by the chairman;

FIG. 10 depicts an index split process of each non-chairman with a copy of the index atom being split; and

FIG. 11 is a flow diagram useful in understanding the processing of messages stored during a split operation.

DETAILED DESCRIPTION

FIG. 1 depicts an implementation of an elastic, scalable, on-demand, distributed database system 30 that operates over a plurality of nodes. Nodes N1 through N6 are “transactional nodes” that provide user access to the database; nodes A1 and A2 are “archival nodes” that act as storage managers and function to maintain a disk archive of the entire database at each archival node. While an archival node normally stores the entire database, a single transactional node contains only that portion of the database it determines to be necessary to support transactions being performed at that node at that time.

Each node in FIG. 1 can communicate directly with each other node in the system 30 through a database system network 31. For example, node N1 can establish a communications path with each of nodes N2 through N6, A1 and A2. Communications between any two nodes is by way of serialized messages. In one embodiment, the messaging is performed in an asynchronous manner to maximize the bandwidth used by the system thereby to perform various operations in a timely and prompt manner. Typically, the database system network 31 will operate with a combination of high-bandwidth, low-latency paths (e.g., an Ethernet network) and high-bandwidth, high-latency paths (e.g., a WAN network).

Each node has the capability to restrict use of a low-latency path to time-critical communications (e.g., fetching an atom). The high-latency path can be used for non-critical communications (e.g., a request to update information for a table). Also, and preferably, the data processing network of this invention incorporates a messaging protocol, such as the Transmission Control Protocol (TCP) and assures that each node processes messages in the same sequence in which they were sent to it by other nodes.

FIG. 2 depicts a representative transactional node 32 that links to the database system network 31 and various end users 33. The transactional node 32 includes a central processing system (CP) 34 that communicates with the database system network 31 through a network interface 35 and with the various users through a user network interface 37. The central processing system 34 also interacts with RAM memory 38 that contains a copy of the database management program that implements this invention. This program functions to provide a remote interface 40, a database request engine 41 and a set 42 of classes or objects. The database request engine 41 only exists on transactional nodes and is the interface between the high-level input and output commands at the user level and system level input and output commands at the system level. In general terms, its database request engine parses, compiles and optimizes user queries such as SQL queries into commands that are interpreted by the various classes or objects in the set 42.

In this system, the classes/objects set 42 is divided into a subset 43 of “atom classes,” a subset 44 of “message classes” and a subset 45 of “helper classes.” At any given time, a transactional node only contains those portions of the database that are then relevant to active user applications. Moreover, all portions of database in use at a given time at any transactional node are resident in random access memory 38. There is no need for providing supplementary storage, such as disk storage, at a transactional node during the operation of this system.

Referring to FIG. 3A, a Master Catalog atom 70 tracks the status of transactional and archival nodes in database system 30 of FIG. 1. It also can be considered as an active index that creates and monitors the Transaction Manager atom 71, the Database atom 72, each Schema atom 73, each corresponding set of Table atoms 74 and Table Catalog atoms 75, and Sequence ID Managers 82. The Table Catalog atom 75 acts as an active index that creates and monitors Index atoms 76, Record States atoms 77, Data atoms 78, Blob States atoms 80 and Blob atoms 81 associated with a single table. There is one Table Catalog atom 75 for each table.

FIG. 3B is useful in understanding the interaction and management of different atom types. In this context, neither the Master Catalog atom 70 nor the Table Catalog atom 75 performs any management functions. With respect to the remaining atoms, the Database atom 72 manages each Schema atom 73. Each Schema atom 73 manages each related Table atom 74 and Sequence ID Manager atom 82. Each Table atom 74 manages its corresponding Table Catalog atom 75, Index atoms 76, Record States atoms 77, Data atoms 78, Blob States atom 80 and Blob atoms 81. Still referring to FIG. 3B, the database request engine 41 communicates with the Master Catalog atom 70, Transaction Manager atom 71, the Database atom 72, each Schema atom 73, each Table atom 74 and the Sequence ID Managers 82. The database request engine 41 acts as compiler for a high-level language such as SQL. As a compiler, it parses, compiles, and optimizes queries and obtains metadata and data from atoms for the formation of the various fragments of data base information.

Each atom has certain common elements and other elements that are specific to its type. For purposes of describing this invention, FIG. 4 depicts an index atom 76 that is implemented as a B-Tree index and is split according to this invention. Element 76A is a unique identification for the index atom 76. Pointers 76B and 76C identify a master catalog atom and the creating catalog atom, respectively. Each atom must have a chairman that performs functions as described later. Element 76D points to the node where the chairman for that atom resides.

Each time a copy of an atom is changed in any transactional node, it receives a new change number. Element 76E records that change number. Whenever a node requests an atom from another node, there is an interval during which time the requesting node will not be known to other transactional nodes. Element 76F is a list of all the nodes to which the supplying node must relay messages that contain the atom until the request is completed.

Operations of the database system are also divided into cycles. A cycle reference element 76G provides the cycle number of the last access to the atom. Element 76H is a list of the active nodes that contain the atom. Element 761 includes several status indicators. Elements 76J contains a binary tree of index nodes to provide a conventional indexing function. Element 76K contains an index level. Such index structures and operations are known to those in skilled in the art.

As previously indicated, communications between any two nodes is by way of serialized messages which are transmitted asynchronously using the TCP or another protocol with controls to maintain messaging sequences. FIG. 5 depicts the basic syntax of a typical message 90 that includes a variable-length header 91 and a variable-length body 92. The header 91 includes a message identifier code 93 that specifies the message and its function. As this invention envisions a scenario under which different nodes may operate with different software versions, the header 91 also includes identification 94 of the software version that created the message. The remaining elements in the header include a local identification 95 of the sender and information 96 for the destination of the message and atom identification 97. From this information, a recipient node can de-serialize, decode, and process the message.

FIG. 6 depicts a set of messages that are helpful in implementing this invention. An Index Split Request message 147 is sent to the chairman by another (non-chairman) atom to institute an index split operation. An Index Split message 148 contains an index atom identifier and the key on which to split the index atom (i.e., a “split key”). An Index Split Start message 160 indicates that the chairman has begun processing the split and is broadcast to all nodes with a copy of the index being split. An Index Split Done message 161 indicates that a node has completed the split operation.

FIG. 7 broadly discloses a process 200 for implementing an index splitting function in accordance with this invention. This disclosure can be better understood by referring to FIG. 8 in which FIGS. 8A through 8D depict the state of the index at various stages of the process as initiated by a non-chairman node. Specifically, FIG. 8A depicts an un-split index 201C where “C” designates an index atom located at the chairman's node. Another copies of the index atom are designated as 20 IN to indicate that they are located in a node that does not contain the chairman. FIG. 8A also discloses the index 201C at the chairman node as comprising a lower portion 202C and an upper portion 203C. Similarly, the index 201N in a non-chairman node comprises a lower portion 202N and an upper portion 203N.

If either the chairman or a non-chairman index node needs to be split, only the chairman controls the splitting operation. If the chairman determines that the atom 201C requires splitting, step 204 transfers control to step 205 whereupon the chairman selects a key value upon which to base the split. In FIG. 8 this value is represented by a vertical dashed line 206C and typically would be chosen so that a lower portion 202C and an upper portion 203C have approximately the same size. If the non-chairman determines that its index atom needs to be split, the non-chairman generates an Index Split Request message at step 208 with a split key value corresponding to a split position 206N. As will be apparent, either request is directed to step 207 whereupon the chairman takes control of the operation.

At step 207, the chairman broadcasts an Index Split Started message to all nodes having a copy of the index atom to be split. Each receiving node responds to the Index Split Started message by buffering and processing subsequent incoming messages in the nodes that include the index atom to be split. As the chairman now controls split, further operations will involve the index atom 201C.

Next, the chairman creates a new index atom at step 210 shown as an empty atom 211C in FIG. 8B. This new index atom then becomes the right sibling of the index atom being split by the chairman and the left sibling of the index atom that had been the right sibling prior to the split. Then the chairman transfers control to an index split process 212 to split the index as shown in FIG. 9 wherein the chairman uses step 213 to determine a key value of the index upon which to base the splitting operation; i.e., a split key value. As previously indicated, that value is established by the chairman or non-chairman that originates the request and defines a boundary in the index atom between the lower and upper key value ranges. The chairman uses this information to place all the keys in the upper key value portion into the new index atom and to truncate the original index by deleting the keys with values in the lower portion as shown in FIG. 8C.

In step 214 of FIG. 9 the chairman broadcasts an Index Split message to all other nodes that contain an existing index atom including the chairman and non-chairman nodes in FIG. 7 and all other non-chairman nodes. At the chairman atom, this message initiates a process for assuring that messages received for and generated by the chairman atom have correct addresses for the left and right siblings for certain messages. An Index Node Added message 150 in FIG. 6 indicates that a new index node is added and contains an index key, record identification and other information and an Index Node Removed message contains corresponding information concerning the removal of an index node. From the occurrence of the split in the chairman node in step 214 until the end of the splitting operation there exists the possibility that non-chairman nodes may not have processed the split. Each time one of these messages is received during this interval, messages received at the left sibling that should be processed on the right sibling are rebroadcast from the right sibling. Messages received at the right sibling are rebroadcast from the left sibling.

This process continues until the chairman receives Index Message Done messages from all the other nodes/atoms involved in the split operation. When this occurs, step 217 terminates the rebroadcasts of step 215 and broadcasts an Index Split Done message 161 to all the nodes with a copy of the index atom.

When a non-chairman node receives an Index Split message from the chairman, an Index Split process 220 in FIG. 7 and shown in more detail in FIG. 10 begins. Each non-chairman node responds to that message by truncating its existing index atom 201N at step 222 to obtain a copy of the chairman's index atom as shown in FIG. 8C that becomes the left sibling of the new index atom. Step 223 obtains a copy of the populated new index 211C as shown in FIG. 8D which becomes the lower portion of the new index atom and prevents any processing on the keys from the right sibling.

Next step 224 “prunes” the right sibling by adding all its local keys from the upper portion copy 213N as also show in FIG. 8D. This occurs before allowing any message processing on the right sibling 213N and assures that all messages are processed against the same indexes as if no split had occurred. Next step 225 allows the non-chairman to begin to process any messages directed to it. Step 227 broadcasts an Index Split Done message to all the nodes with an existing index atom copy. This signifies that foregoing processing has been completed at the respective node. Control then transfers from process 220 back to the chairman Index Split Process 214 shown in FIG. 9. Specifically, as shown in FIG. 9, at this point the chairman broadcasts an Index Split Message to all of the nodes with an existing atom copy whereupon control transfers to a non-chairman tracked message process 230 as shown in FIG. 11.

Referring now to FIGS. 7 and 11, a stored message process 230 uses step 231 to divert control to step 232 to process each message received at that node for the index atom. When an Index Split Start message is received, step 231 diverts control to step 233 that responds to the receipt of the Index Split Done message in step 233. During the interval between these two messages, steps 231 and 233 divert control to step 234 to buffer each incoming message at step 234. Each message includes its atom ID, sender ID represented by anode number and a change number. If step 234 receives a first message or new message not previously received, step 235 diverts control to record the message in some manner, as by entry in a bit map at step 236. Then the message is processed. If step 235 determines that the bit map has recorded the receipt of that message from another node, control transfers to step 237 to drop or ignore the message because it is a duplicate. Consequently, redundant processing does not occur.

As will now be apparent, this invention ensures that an index in a distributed database can be split in a concurrent and consistent fashion even though copies of that index may exist at multiple nodes at which data processing occurs. This occurs without any need to quiesce the system so there is no significant performance degradation. Also, this invention eliminates the involvement of nodes that do not include that specific index.

This invention has been disclosed in terms of certain implementations that are directed to a specific implementation of a distributed database. Although the invention is disclosed for in one specific implementation, the application to other implementations will be apparent to others without departing from the invention. Therefore, it is the intent of the appended claims to cover all such variations and modifications as come within the true spirit and scope of this invention. 

What is claimed as new and desired to be secured by Letters Patent of the United States is:
 1. A method of splitting a first index atom in a plurality of atoms in a distributed database, the distributed database being distributed over a plurality of nodes, each node in the plurality of nodes comprising a corresponding processor and a corresponding memory to store replicas of at least some atoms in the plurality of atoms, each atom in the plurality of atoms containing a specific fragment of data and/or metadata of the distributed database, the plurality of atoms collectively representing all the data and/or metadata in the distributed database, the method comprising: at a first node in the plurality of nodes, the first node comprising a first processor and a first memory: selecting a split key value that defines first and second portions of the first index atom, the first index atom including a first fragment of the data and/or metadata associated with an index of a first table in the distributed database, creating a second index atom as a sibling of the first index atom, transferring key values in the second portion of the first index atom to the second index atom, and sending an index split message to a second node in the plurality nodes, the index split message including the split key value, the second node comprising a second processor and a second memory; and in the second node: generating a replica of the second index atom in response to the index split message; responding to the index split message by moving key values from a replica of the first index atom to the replica of the second index atom, the key values corresponding to the key values in the second portion of the first index atom, and sending a split done message to the first node, the split done message indicating that the replica of the first index atom at the second node has been split. 